A pathway for healthcare to join the design disciplines
Arnold KIM
line 2: dept. name of organization
(of Affiliation)
line 3: name of organization
(of Affiliation)
line 4: City, Country
line 5: email address or ORCID
Laila Ikki
line 2: dept. name of organization
(of Affiliation)
line 3: name of organization
(of Affiliation)
line 4: City, Country
line 5: email address or ORCID
Sabah Mohammed
line 2: dept. name of organization
(of Affiliation)
line 3: name of organization
(of Affiliation)
line 4: City, Country
line 5: email address or ORCID
Samia Ishaque
line 2: dept. name of organization
(of Affiliation)
line 3: name of organization
(of Affiliation)
line 4: City, Country
line 5: email address or ORCID
Jinan Fiaidhi
line 2: dept. name of organization
(of Affiliation)
line 3: name of organization
(of Affiliation)
line 4: City, Country
line 5: email address or ORCID
Abstract— Given the increasing complexity of patient cases due to an aging population and multimorbidity, it has become essential to capture encounters between patients and physicians with greater nuance. The current method of using Electronic Health Records (EHRs) is limited in its ability to do so. This is because EHRs mostly arrange discrete concepts information using static spatial allocation of widgets to denote data typesin static widgets, which are navigated by physicians in order to cognitively formulate ther to form relationships between elements on the go. This results in cognitive overload experienced by physicians as well as data fragmentation. Moreover, it lacks the ability to express the discrete elements with the non-discrete. For example, expressing why (non-discrete) a lab (discrete) was ordered for a patient. This paper is proposed by Aurora, a group of people working on resolving these challenges with the proposed framework. The Aurora framework introduces the ideal properties for modeling and design in healthcare such as expressiveness and information synthesis. Moreover, it builds a solution using domain specific languages to achieve these properties.
Keywords—component, formatting, style, styling, insert (key words)
I. Patient Case representation space in healthcare
Complex clinical decision-making is at the forefront of modern medicine. Patient heterogeneity can now be captured with greater nuance, propelling a shift towards more individualized evidence-based care, or precision medicine [1]. For example, advancements in molecular genetics have enabled indicators such as genetic predisposition and biomarker identification to deeply stratify the patient profile [1]. As such, the construction of an optimal treatment plan is predicated on a thorough understanding of all these elements as they relate to each other and as they interact with one another. Moreover, the aging population in North America tends to contribute another layer of complexity to the clinical reasoning process, where there is an influx of patients with chronic conditions that necessitate ongoing management. Multimorbidity is to be expected in members of this age group, and they are more likely to be admitted (and readmitted) to the hospital with longer lengths of stay and greater instances of polypharmacy [2]. All of these dynamic components constitute the ever-evolving patient chart, and all need to be considered when developing, or designing, a treatment plan.
That being said, there is more to the patient portfolio than empirical observations. In fact, healthcare providers use many non-discrete elements, ranging from body language to tone of voice when shaping a holistic understanding of their patients. These kinds of observations resist traditional modes of measurement because they are difficult to quantify. In fact, there has always been doubt as to whether notions like quality of life or happiness can be truly captured using a numerical scale. In this way, medicine is a human science in both the literal and figurative senses of the phrase一both a science and an art. Reconciling between these two very different spheres is both the labor and fruit of medicine. Healthcare providers continuously juggle the increasingly elaborate genetic screenings, laboratory test results, and clinical observations with the uncertainty and ambiguity concomitant with the discipline. This makes the compounding complexity of medical data an inevitable part of the clinical workflow.
During the diagnosis, treatment and management of medical conditions, the sheer volume of information that a healthcare provider must consider is colossal. It seems as though there is no feasible way to condense it all onto one small computer screen, and any attempt to do so would be similar to trying to view a large room from a keyhole. This is because EHRs present discrete concepts using static spatial allocation of widgets to represent data types. Accessing all the information needed in order to 1) construct a sound image of the patient and 2) design an optimal treatment plan, is therefore an example of the keyhole effect [3]. The healthcare provider is unable to see the big picture because the widgets reduce the amount of information that can be viewed at a particular moment in time [3].
Since one screen does not provide sufficient space for even all the laboratory test results (let alone for documentation or any notes the provider wishes to highlight), modern electronic health records (EHRs) distribute medical data across multiple pages. This is a problematic workaround. Information fragmentation causes relevant content to be spread out, both within an EHR and beyond [4]. The dispersion of information in this manner necessarily conceals any relationships that may exist therein. Such highly fragmented medical data is difficult to access at point-of-care, which impairs the clinical decision-making process and leads to a disrupted clinical workflow [4]. Since healthcare providers need to constantly consult multiple screens, or frequently navigate to different parts of screens, in order to view all the relevant clinical information, they suffer from severe display fragmentation [4].
Figure 1: Screen fragmentation and lack of synthesis of relationships (Problem)
This is taxing on the healthcare provider in two ways: Firstly, there is a manual component, which involves repeated clicking, scrolling, as well as data entry and retrieval. While this may seem insignificant, many healthcare providers report spending more time with pull-down menus than with patients [5]. These manual searches are also pain points during the clinical workflow because they prevent the healthcare provider from completing the task more efficiently.
Next, and perhaps even more importantly, there is the cognitive component. Here, the disjointed nature of medical data shown in figure 1, forces healthcare providers to retain information pertaining to the case in working memory, even as they continue to search for other points of relevance. This is known as cognitive load [3]. Since display fragmentation purges medical data of the relationships that may exist therein, healthcare providers are expected to perform information retrieval and synthesis in parallel, often in highly stressful and time-sensitive situations. Over time, such cognitively-straining activities can lead to dissatisfaction, frustration, and ultimately burnout [4].
The current EHR setup is incompatible with the clinical workflow. In other words, there is a task-system mismatch, so the attention that should be dedicated to performing the task at hand (i.e., designing the medical plan) is regularly interrupted due to system navigation [4]. Instead of facilitating task completion, the system actually impedes it. There is an opportunity here to draw some similarities between the goals of healthcare providers and those of engineers and artists: Healthcare providers are architects of the patient’s treatment plan. Their job is to draft, propose, adapt, and revise medical plans, following the same iterative cycle used by other domains (e.g., an engineer preparing drafts for a bridge, a graphic designer sketching a three-dimensional model). One cannot help but notice, however, there is a glaring toolkit disparity in healthcare. Considering that engineers can use AutoCad and graphic artists can make use of Photoshop, there is a marked robustness gap in the tools currently used by healthcare providers. These tools help engineers and artists draw relationships between elements and prioritise synthesis of information.
Like other disciplines, medicine is profoundly collaborative. However, where other industries have streamlined the joint drafting capabilities of a multidisciplinary team, healthcare is lagging sorely behind. In a field where non-discrete elements like patient wishes are evaluated just as importantly as laboratory test results, there is a marked complexity in striving to achieve a coherent synthesis between members of the primary care unit. As a matter of fact, continuity of care is near impossible to achieve without the ability for team members to recognize and develop an overarching synthesis in their treatment planning. There is therefore a desperate need for a design space conducive to the complex clinical tasks cape, but this would necessitate a complete shift in paradigm.
To give you an example, let us take a care scenario that illustrates the difficulty of using EHRs. Assume that all discrete concepts represented here are already pre-mapped to established ontologies elsewhere for the sake of simplicity:
Scenario: A physician must represent their impressions and orders on a patient presenting with CHF. It is suspected to be 2ndary to a type2 NSTEMI. The patient also presented with atrial fibrillation. The physician decides to order a cardiology consult, medicines - asa 160 mg, furosemide 20 mg IV, metoprolol 25mg and oxygen to keep saturation above 94%. They are uncertain about metoprolol and suggest waiting for bp to stabilize.
Modern day EHRs are limited in their ability to represent this scenario with discrete data using the variety of data attributes available within the EHRs system. In this scenario, the physician wishes to note the observations made on admitting the patient and the orders they gave while also building relationships between these observations and orders. We face the challenge of adding subjective to the objective such as providing nuance for why a certain medicine is prescribed or how long doctors should wait before administering another medication.
Figure 2 illustrates this scenario in greater detail. The symbol ‘?’ represents lack of certainty and “!” represents negation. The patient presents with chest pain and on examining the issues are classified as chf and afib. The issue nstemi is unsure and needs to be verified with the opinion of the cardiology department. This diagram draws a relationship between all issues as chf and afib are linked to nstemi, showing that these issues occur due to nstemi. Moreover, it also adds narrative to issues and orders to help understand them better. For example, the narrative attached to metoprolol warns against administering the medicine before blood pressure stabilizes. EHRs have limited capability to draw these relationships, limiting their expressiveness. Instead, data is fragmented and these relationships are built by healthcare workers in real time.
Figure 2: Diagram for patient care scenario
Healthcare is challenged by an increasingly complex discrete concept space, knowledge space, while also having to incorporate concepts and ideas that resist discretization thus the utility of narrative. Relationships between these spaces are paramount for validation, minimizing cognitive load, team collaboration, automation and data analytics. Historically, healthcare's representation space is heavily dependent on statically arranged widgets to delineate data types, and documentation (which captures the indiscrete but is also used as weak substrate for expressing relationships).
To address these challenges, it is important to recognize the need for representing not only discrete ( i.e. labs, medicines and orders) but also the non-discrete (i.e. the rationale, narrative and care orders flow) elements especially from the perspective of the caregiver according to the patient case progression. However, given the excessive workload healthcare providers face, complex softwares that require coding or technical expertise are often resisted. Clinical practice provides primitive tools to express issues, medicine, diagnosis et cetera and asks clinicians to synthesize on the go. Therefore it is essential to move to solutions that capture relationships between components of the patient care model with a low code approach. Therefore, Aurora ( the term ‘Aurora’ is used in this paper to represent the proposed solution as well as the group of researchers who came up with this approach) achieves this feat largely using the power of domain specific languages. Domain-specific languages (DSLs) are versatile tools that offer a blend of structured representation and expressive capabilities. DSL is a mechanism for synthesizing the information clinicians compose. Using DSL, we can generate a language specific to healthcare that not only captures what doctors do but is also machine understandable. It is essential that the design environment facilitates both the rapid learning of the DSL as well as overall being able to achieve complex design objectives.
To explain this solution in detail and provide a clear understanding of this approach, this paper is organized in the following manner. Section II highlights the list of ideal properties for modeling and design, Section III explains the patient care model as a DSL using Aurora language, Section IV outlines the benefits of Aurora. Section V is about the impact on teaching and learning. Finally Section V presents the conclusion with limitations and future directions.
II. Ideal Properties for Modeling and Design
Before we discuss the solutions to the aforementioned problems, it is important to outline the principles on which any designing solution should be based. The solution proposed by Aurora focuses on the following principles:
Expressiveness
EHRs record both structured and unstructured data. Structured refers to numerical or categorical values from diagnosis, medication, and laboratory values. On the other hand, unstructured data exists in the form of free-form text such as clinician notes and discharge summaries [6]. Unstructured data makes up 80% of the total data in EHRs but it is largely under-utilized due to difficulty in extracting relevant data from documentation [6]. This is because it is difficult to form relationships between elements in unstructured data without extracting them. While Natural Language Processing (NLP) and Deep Learning have shown promise in extracting information, the nature of unstructured data is becoming more complicated. Due to increasing complexity, EHR will contain information never seen before by these models. Therefore, it is essential to find tools that efficiently manage unstructured data [7]. Therefore, the model should be able to represent patient data, incorporating both discrete and non-discrete elements in a manner that both humans and machines can understand. It should make it easier to extract information from unstructured data. This level of expressiveness can be achieved through a fluid design space that supports dynamic change and iterative exploration. Such a design space should consist of adaptable elements to represent the patient care model.
Synthesis of Information
In an EHR system, users have to click through varying screens to view all the information. They have to go through information sequentially and keep information in memory to draw relationships between different components scattered between screens [4]. Such fragmentation of information can lead to inaccuracies and suboptimal diagnostic reasoning [4]. Moreover, it leads to cognitive load. It is important to model information in a way that makes it easier to draw relationships between components. This can be achieved by modeling information in a composable manner, where clinical components of the patient care model can be represented modularly, combined and also visualized. This supports rapid construction towards synthesis.
Collaborative Drafting
Healthcare requires active collaboration between departments,allied health teams, and clinicians while updating a patient case. For example, clinicians presented with the patient case outlined in Figure B would have to collaborate confirming nstemi diagnosis with the cardiology team. However, EHR “does not facilitate shared documentation that could be incrementally added between and across roles and specialties for the same patient.[8]”
Members of the primary care unit should have access to the evolving status of the patient, as well as to the opinions of their colleagues, without needing to manually screen pages of documentation and charts.
Magnification of Detail
Toggling between high-level and low-level views enables clinicians to continuously check in on the big picture all the while making adjustments in highly localized areas of the patient plan. High-level views make the relationships between coordinates of care more explicit (presenting them as constellations if you will), lowering the cognitive burden and centering the workflow on design.
Don't Repeat Yourself (DRY) Principle
The DRY principle was introduced in software development to minimize the repetition of code and promote a modular approach. In EHRs, this would mean standardizing the unstructured data in documentations. This is because documentation is a free-form text format which can often repeat itself without forming relationships between the elements [6]. To design an efficient system, the DRY principle should be applied to modularize the EHR into reusable concepts that can be combined and reused.
Contemporaneous Learning and Decision Support
The design solution should be able to help users learn and navigate the system on the go. For example, Integrated Development Environments (IDE) help programmers understand and debug their code as they are coding. Similarly, EHRs should be able to explain patient issues, medicines, results et cetera to the user. This would reduce the cognitive load for physicians as they can dedicate time to more pressing tasks rather than trying to understand basic treatment policies.
III. Envisioning Patient Care Model as Domain Specific Language (DSL)
Let us examine how these design principles are achieved by the Aurora framework by building the patient care model as a DSL. This section presents a simple patient case represented through the Aurora framework and builds upon that to present a patient case progression.
Aurora Framework
The Aurora framework makes use of Langium to write grammar specific to the patient care model. This consists of important elements like ‘Issues’, ‘Orders’ and, ‘Narratives’ to represent the patient encounter. In a regular patient-physician encounter, the patient discusses issues with the physician. Then, the physician investigates to confirm these issues and gives orders to draw up a treatment plan. Some orders may need subjective information, which is highlighted as ‘narratives’ in Aurora language. In the solution proposed by Aurora, the protocols needed to construct a treatment plan are part of the policy. Upon entering the patient issues, a medical plan is rapidly constructed from the policy for the physician. This workflow is also demonstrated through the diagram in Figure 3.
Figure 3: Drafting a treatment plan
In the Aurora language, this is presented as the following pseudocode:
Issues:
chf
Orders:
furosemide[chf]
It is important to note that this solution builds a relationship between the order and issue, linking furosemide to chf. Using this pseudocode, the Aurora language generates an abstract syntax tree (AST) for this scenario. An AST represents the syntax of a language without going into the details such as white spaces or parenthesis, et cetera. This AST exists as a ‘.ts’ file but when parsed, it can be visualized as shown:
This representation can be further expanded by adding more links and paths such as adding narratives to orders or adding more issues. This solution aligns with the design principles outlined in section II as it not only helps express discrete and non-discrete concepts together but also builds relationships between elements drawing cross-references between nodes of the AST.
This illustrates how multiple discrete concepts can be laid out in a manner where their data types are delineated by syntax and not just by the static arrangement of widgets. Moreover, relationships between various data types are explicitly encoded as each order is connected to a certain care problem in the problem list.
Other than building relationships between problems and orders, this combines the discrete and non-discrete using double slashes. The double slashes are inspired by the classical comments used in programming and provide narrative to add to the discrete concept map that emerges. Is this documentation, orders or data entry? Arguably this is all of the above. It is both machine and human readable. In this way clinical documentation could exist in-line with medical orders and prescriptions. The immediate effect is access to the clinical reasoning process of other members of the primary care team, and the elimination of possible confusion resulting from unexplained orders.
Arranging information in this way also reduces data fragmentation and the cognitive load of frontline healthcare workers. Rather than navigating between widgets to gather information, this reshapes the design space to make information more accessible and easily readable.
Let us understand the solution in more depth using a patient case progression example:
Patient Case Progression
For the sake of simplicity, let us assume that all shorthand and terms such as nstemi, chf, furosemide and asa are mapped to appropriate ontology terms by the author of the local policy elsewhere.
Each step below presents the progression of the case with a pseudocode of the DSL along with a reference to the visualization of the abstract syntax tree.
Step 1: Patient is admitted to the hospital and an initial charting is done by a student. They only identify issues and add a consult to the patient chart.
ProblemList:
?nstemi1 //could be type 2 nstemi being 2ndary to a.fib and chf. need cardiology opinion
afib [?nstemi1]
chf[nstemi1 ]
Orders:
consult cardiology stat [nstemi1 ,afib,chf]
o2[chf] //try to keep sats > 94%
Step 2: After a cardiology consult confirms issues and nstemi1, the resident adds medicines to the orders. The highlighted text reflects the changes that have been made.
ProblemList:
nstemi1 //confirmed by cath
afib [nstemi1]
chf[nstemi1 ]
Orders:
Diagnosis [nstemi1 ,afib,chf]
asa [nstemi1 ] 160 mg po now
furosemide [chf] 20 mg iv now //there was an initial dip in blood pressure, however o2 sats are low and cxr showing significant pulmonary edema, we need to monitor closely
!metoprolol [afib,nstemi1 ] 25 mg po now //will await bp showing more stability before starting this
o2[chf] //try to keep sats > 94%
Step 3: The chart is concluded by the chief architect after the blood pressure of the patient stabilizes
ProblemList:
nstemi1
afib [nstemi1]
chf[nstemi1 ]
Orders:
Diagnosis [nstemi1 ,afib,chf]
asa [nstemi1 ] 160 mg po now
furosemide [chf] 20 mg iv now //there was an initial dip in blood pressure, however o2 sats are low and cxr showing significant pulmonary edema, we need to monitor closely
metoprolol [afib,nstemi1 ] 25 mg po now
o2[chf] //try to keep sats > 94%
IV. Benefits of the Aurora solution
It is important to understand the benefits of this solution in light of challenges faced by clinicians in daily practice. This section outlines these challenges and also describes how the Aurora solution rises to solve them.
Computerized Physician Order Entry
Order entry is a crucial part of the clinical workflow. Physicians require the process to be simple, promoting information synthesis and collaboration amongst staff. A study conducted by [9] collected 557 reports from clinicians to study safety challenges due to EHRs. The challenges facing EHRs were divided into ‘usability’ and ‘clinical process’ categories. Among usability issues, it highlights that “EHR data entry is difficult and not possible” as it does not align with the clinicians’ work process. The clinical example for this problem mentions that the physician ended up entering the wrong dosage frequency due to the data entry process being confusing. Furthermore, clinicians find it hard to interpret information as the information is “confusing and cluttered. [9]”
The clinical process highlights a scenario in which the order placed to administer a medicine to the patient disappeared and was marked grey on the Medication Administration Record without being completed by anyone. The nurse remarked that this had previously been happening with doctors’ orders on night shift [9]. These scenarios not only help understand the challenges due to EHRs but also show how important the Aurora solution is. Aurora wishes to make the process of entering patient-related information more intuitive. It addresses the ‘usability’ challenge as upon entering issues, the medical treatment plan is built for the clinicians. For now, this solution is limited to generic issues such as congestive heart failure but in the future we hope to expand it so that one can build reusable treatment plans on the go. It also addresses clinical process scenarios as building visual relationships between components would help clinicians visualize the plan. This should help identify any unwanted medicines or dosages in time.
Documentation
The same report [9] has also identified documentation as clinical process related concern due to EHRs. In the scenario it mentions that a patient with two EHR encounters was admitted. The physician orders were under one encounter whereas the documentation was on another encounter. There was no way of combining these documentations to see the orders on both encounters [9]. This scenario highlights that while it is true that current EHRs support unit documentation, there isn’t a way to extract relevant orders to help understand the patient’s case across encounters. This leads to fragmentation, where clinicians have to build the case themselves and it contributes to the cognitive load. The solution proposed by Aurora wishes to use narratives to link the discrete and non-discrete. Rather than going through a large number of documentations, clinicians should be able to add subjective information and reasoning to their decisions on the go. This would not only save time repeating information (drug dosage, laboratory results, etc) but also means that it is easier for other clinicians to understand and carry out orders.
Manual Patient Handover
During a patient’s stay at the hospital, they may be treated by several departments and various health-care practitioners. As hospitals today operate for 24 hours, primary medical teams have to routinely transfer patients to the team that is on-call [10]. This process of transferring is called a handover. A study was conducted at a hospital to study the challenges facing handovers during a time where a single health-care provider is overlooking a high number of patients. The quality of handover was observed and one of the problems identified was the inadequate transfer of critical information [10]. Despite some of the cases being serious, there was an information loss. It was also noted that most of this loss happened during verbal communication. On average, the study shows that the primary team physicians and the on-call team discuss 9.8 categories of information per patient case but only 5.5 information categories were written down. This meant that there was a risk of losing about 40% information regarding the patient as it is difficult for healthcare providers to retain patient information in memory [10].
The Aurora solution aims at making patient handovers easier for clinicians. The idea behind this is to visualize the patient case using the treatment plan. Unlike EHRs, Aurora pulls up a treatment plan relevant to the issue, visualizes the relationship and also adds narrative to orders. Rather than concentrating a bulk of the information about patients during handovers, it is easier to add these components to the patient treatment plan as you go. Even more important than visualization is the ability to handover using the higher level views of the patient. If more detail is needed, one can zoom in for a higher level of detail.
Billing
Another complicated area of healthcare is patient billing. It is vital to achieve accuracy in this arena as false information could lead to serious complications like claims being denied, patients being wrongfully over or under charged, and even legal issues. The aforementioned problems highlight that given the burden faced by healthcare providers and the design flaws in EHRs, there are bound to be billing discrepancies over time. As the Aurora solution helps make order entry easier and more efficient, it would directly contribute to an increase in billing accuracy.
IV. Impact on Teaching and Learning
There is a long road to teaching and learning design tools in healthcare. Given the rigorous level of training clinicians go through during their education, it can be difficult to incorporate learning about EHRs or design tools. Moreover, experienced clinicians are often too burdened with their workload to learn new systems on their own. However, it is important that senior clinicians and students collaborate to overcome these challenges. Therefore, a proposed solution to this problem is that senior clinicians can provide their invaluable guidance as the senior architect in teaching environments (Clinical Teaching Units). They can also direct students on conducting further important research and innovation towards building and learning these tools. Given that students are often eager to learn and research, it would introduce them to this concept at a stage where they are willing to adapt to new ideas. On the other hand, senior clinicians would also benefit from the collaboration by furthering their knowledge on design tools.
Moreover, it is important to introduce contemporaneous learning and decision support to modeling tools in healthcare. Given this barrier to learning, it is crucial to make physicians' lives easier so that they can learn about key definitions, treatment plans, short codes, et cetera on the go. This is incorporated in the Aurora solution as hovering over an issue gives the physicians a short definition of it. To understand this, let us look at the following pseudocode:
ProblemList:
?nstemi1 //could be type 2 nstemi being 2ndary to a.fib and chf. need cardiology opinion
This pseudocode demonstrates that when a physician hovers over nstemi they get the definition for it.
V. Conclusion
Aurora is a grass roots push towards adapting design tools in health care through the academic community. If successful we would create a new chapter in medical informatics. This movement has resounding benefits in terms of improving patient care and also easing the workload on physicians and allied staff. We hope to inspire the academic and health care industry to build a better system based on what has been already learned in the design disciplines.
As a part of the future work for this project, Aurora endeavourshopes to keep adding more design principles inspired by other design disciplines in their design tools,to advance the visualization and efficacy of the patient care design experience and downstream effects. The solution provided in this paper is only the first step in the right direction. Moreover, Tthis project also has great potential in the field of machine learning due to the rich structured data generated on the frontline of healthcare. beingbased on learning patient’s encounters and treatment plans.
Finally this opens signficant opportunities for neurosymbolic implementations of AI to mix constraining and deterministic composability to safeguard against non-deterministic and hallucination related behaviours from LLMs. This will improve the collaboration between humans and machine representations of knowledge in terms of human in the loop characteristics since DSLs are understood both by humans and machine entities.
However, this project has also faced various challenges during production. The most fundamental problem is to be able to scale this movement with more health care academic centers and the industry. It is of vital importance to It has been difficult to build a growing community for further development of theory and prototypes to determine whether growing evidence of superiority emerges. Should this occur, then health care and other industries will be tasked with the challenging change management journey of joining with the design disciplines in their usage of modeling/design tools. community and consensus building. Moreover, there has been limited access to healthcare data due to the sensitive nature of information. Having more data would help Aurora build a robust system which can tolerate a large number of requests. There’s also been a barrier to convincing physicians regarding moving to design tools in healthcare. Given the workload physicians have, it is difficult to integrate learning about such tools into their practice.
In conclusion, this paper serves as a great starting point for physicians and engineers to collaborate and move the healthcare system towards design principles. Despite the challenges, Aurora is actively working to improve rapid modular construction of the patient cases while increasing automation, joining with design disciplines to inherit methodologies in optimizing quality, error reduction, productivity and collaboration.
References
[1] Kosorok, Michael R., and Eric B. Laber. "Precision medicine." Annual review of statistics and its application 6, no. 1 (2019): 263-286.
[2] Kingston, Andrew, Louise Robinson, Heather Booth, Martin Knapp, Carol Jagger, and Modem Project. "Projections of multi-morbidity in the older population in England to 2035: estimates from the Population Ageing and Care Simulation (PACSim) model." Age and ageing 47, no. 3 (2018): 374-380.
[3] Senathirajah, Yalini, Suzanne Bakken, and David Kaufman. "The clinician in the Driver’s Seat: Part 1–A drag/drop user-composable electronic health record platform." Journal of Biomedical Informatics 52 (2014): 165-176.
[4] Senathirajah, Yalini, David R. Kaufman, Kenrick D. Cato, Elizabeth M. Borycki, Jaime Allen Fawcett, and Andre W. Kushniruk. "Characterizing and visualizing display and task fragmentation in the electronic health record: mixed methods design." JMIR human factors 7, no. 4 (2020): e18484.
[5] Schulte, Fred, and Erika Fry. "Death by 1,000 clicks: Where electronic health records went wrong." Kaiser Health News 18 (2019).
[6] Li, Irene, Jessica Pan, Jeremy Goldwasser, Neha Verma, Wai Pan Wong, Muhammed Yavuz Nuzumlalı, Benjamin Rosand et al. "Neural natural language processing for unstructured data in electronic health records: a review." Computer Science Review 46 (2022): 100511.
[7] Shah, Shahid Munir, and Rizwan Ahmed Khan. "Secondary use of electronic health record: Opportunities and challenges." IEEE access 8 (2020): 136947-136965.
[8]Moy, Amanda J., Mollie Hobensack, Kyle Marshall, David K. Vawdrey, Eugene Y. Kim, Kenrick D. Cato, and Sarah C. Rossetti. "Understanding the perceived role of electronic health records and workflow fragmentation on clinician documentation burden in emergency departments." Journal of the American Medical Informatics Association 30, no. 5 (2023): 797-808.
[9] Howe, Jessica L., Katharine T. Adams, A. Zachary Hettinger, and Raj M. Ratwani. "Electronic health record usability issues and potential contribution to patient harm." Jama 319, no. 12 (2018): 1276-1278.
[10] Yang, Xi Jessie, Taezoon Park, Tien Ho Kewin Siah, Bee Leng Sophia Ang, and Yoel Donchin. "One size fits all? Challenges faced by physicians during shift handovers in a hospital with high sender/recipient ratio." Singapore medical journal 56, no. 2 (2015): 109.
